『Lean Architecture』
for Agile Software Development
https://gyazo.com/a51f3989b7ed49042059305b5a895966
Lean is about complicated things; Agile is about complexity.
（p.13）
Speed and flexibility may be results of Agile, but that's not what it is. The common laws behind every principle of the Manifesto are self-organizasion and feedback.
（p.23）
目次
Copyright
Publisher's Acknowledgments
About the Authors
Preface
1. Introduction
1.1. The Touchstones: Lean and Agile
1.2. Lean Architecture and Agile Feature Development
1.3. Agile Production
1.3.1. Agile Builds on Lean
1.3.2. The Scope of Agile Systems
1.4. The Book in a Very Small Nutshell
1.5. Lean and Agile: Contrasting and Complementary
1.5.1. The Lean Secret
1.6. Lost Practices
1.6.1. Architecture
1.6.2. Handling Dependencies between Requirements
1.6.3. Foundations for Usability
1.6.4. Documentation
1.6.4.1. Code Does Not Stand Alone
1.6.4.2. Capturing the "Why"
1.6.5. Common Sense, Thinking, and Caring
1.7. What this Book is Not About
1.8. Agile, Lean — Oh, Yeah, and Scrum and Methodologies and Such
1.9. History and Such
2. Agile Production in a Nutshell
2.1. Engage the Stakeholders
2.2. Define the Problem
2.3. Focusing on What the System Is: The Foundations of Form
2.4. Focusing on What the System Does: The System Lifeblood
2.5. Design and Code
2.6. Countdown: 3, 2, 1 . . .
3. Stakeholder Engagement
3.1. The Value Stream
3.1.1. End Users and Other Stakeholders as Value Stream Anchors
3.1.2. Architecture in the Value Stream
3.1.3. The Lean Secret
3.2. The Key Stakeholders
3.2.1. End Users
3.2.1.1. Psyching Out the End Users
3.2.1.2. Don't Forget Behavior
3.2.1.3. The End User Landscape
3.2.2. The Business
3.2.2.1. A Special Note for Managers
3.2.3. Customers
3.2.3.1. ...As Contrasted with End Users
3.2.3.2. "Customers" in the Value Stream
3.2.4. Domain Experts
3.2.4.1. No Ivory Tower Architects
3.2.4.2. Experts in Both Problem and Solution Domains
3.2.5. Developers and Testers
3.3. Process Elements of Stakeholder Engagement
3.3.1. Getting Started
3.3.2. Customer Engagement
3.4. The Network of Stakeholders: Trimming Wasted Time
3.4.1. Stovepipe Versus Swarm
3.4.2. The First Thing You Build
3.4.3. Keep the Team Together
3.5. No Quick Fixes, but Some Hope
4. Problem Definition
4.1. What's Agile about Problem Definitions?
4.2. What's Lean about Problem Definitions?
4.3. Good and Bad Problem Definitions
4.4. Problems and Solutions
4.5. The Process Around Problem Definitions
4.5.1. Value the Hunt Over the Prize
4.5.2. Problem Ownership
4.5.3. Creeping Featurism
4.6. Problem Definitions, Goals, Charters, Visions, and Objectives
4.7. Documentation?
5. What the System Is, Part 1: Lean Architecture
5.1. Some Surprises about Architecture
5.1.1. What's Lean about This?
5.1.1.1. Deliberation and "Pull"
5.1.1.2. Failure-Proof Constraints or Poka-Yoke
5.1.1.3. The Lean Mantras of Conservation, Consistency, and Focus
5.1.2. What's Agile about Architecture?
5.1.2.1. It's All About Individuals and Interactions
5.1.2.2. Past Excesses
5.1.2.3. Dispelling a Couple of Agile Myths
5.2. The First Design Step: Partitioning
5.2.1. The First Partition: Domain Form Versus Behavioral Form
5.2.2. The Second Partitioning: Conway's Law
5.2.3. The Real Complexity of Partitioning
5.2.4. Dimensions of Complexity
5.2.5. Domains: A Particularly Interesting Partitioning
5.2.6. Back to Dimensions of Complexity
5.2.7. Architecture and Culture
5.2.8. Wrap-Up on Conway's Law
5.3. The Second Design Step: Selecting a Design Style
5.3.1. Contrasting Structuring with Partitioning
5.3.2. The Fundamentals of Style: Commonality and Variation
5.3.3. Starting with Tacit Commonality and Variation
5.3.4. Commonality, Variation, and Scope
5.3.5. Making Commonalities and Variations Explicit
5.3.5.1. Commonality Categories
5.3.5.2. Next Steps
5.3.6. The Most Common Style: Object Orientation
5.3.6.1. Just What is Object Orientation?
5.3.7. Other Styles within the Von Neumann World
5.3.8. Domain-Specific Languages and Application Generators
5.3.8.1. The State of the Art in DSLs
5.3.8.2. DSLs' Place in Architecture
5.3.9. Codified Forms: Pattern Languages
5.3.10. Third-Party Software and Other Paradigms
5.4. Documentation?
5.4.1. The Domain Dictionary
5.4.2. Architecture Carryover
5.5. History and Such
6. What the System Is, Part 2: Coding It Up
6.1. The Third Step: The Rough Framing of the Code
6.1.1. Abstract Base Classes
6.1.2. Pre-Conditions, Post-Conditions, and Assertions
6.1.2.1. Static Cling
6.1.3. Algorithmic Scaling: The Other Side of Static Assertions
6.1.4. Form Versus Accessible Services
6.1.5. Scaffolding
6.1.6. Testing the Architecture
6.1.6.1. Usability Testing
6.1.6.2. Architecture Testing
6.2. Relationships in Architecture
6.2.1. Kinds of Relationship
6.2.2. Testing the Relationships
6.3. Not Your Old Professor's OO
6.4. How much Architecture?
6.4.1. Balancing BUFD and YAGNI
6.4.2. One Size Does Not Fit All
6.4.3. When Are You Done?
6.5. Documentation?
6.6. History and Such
7. What the System Does: System Functionality
7.1. What the System Does
7.1.1. User Stories: A Beginning
7.1.2. Enabling Specifications and Use Cases
7.1.3. Helping Developers, Too
7.1.4. Your Mileage may Vary
7.2. Who is Going to Use Our Software?
7.2.1. User Profiles
7.2.2. Personas
7.2.3. User Profiles or Personas?
7.2.4. User Roles and Terminology
7.3. What do the Users Want to Use Our Software for?
7.3.1. Feature Lists
7.3.2. Dataflow Diagrams
7.3.3. Personas and Scenarios
7.3.4. Narratives
7.3.5. Behavior-Driven Development
7.3.6. Now that We're Warmed Up ...
7.3.6.1. Prototypes
7.3.6.2. Towards Foundations for Decisions
7.3.6.3. Known and Unknown Unknowns
7.3.6.4. Use Cases as a Decision Framework
7.4. Why Does the User Want to Use Our Software?
7.5. Consolidation of What the System Does
7.5.1. The Helicopter View
7.5.1.1. Habits: The Developer View and the User View
7.5.1.2. Trimming the Scope
7.5.2. Setting the Stage
7.5.3. Play the Sunny Day Scenario
7.5.3.1. Business Rules
7.5.4. Add the Interesting Stuff
7.5.5. Use Cases to Roles
7.5.5.1. Roles from the Use Case
7.5.5.2. Bridging the Gap between the Business and the Programmer
7.6. Recap
7.6.1. Support the User's Workflow
7.6.2. Support Testing Close to Development
7.6.3. Support Efficient Decision-Making about Functionality
7.6.4. Support Emerging Requirements
7.6.5. Support Release Planning
7.6.6. Support Sufficient Input to the Architecture
7.6.7. Support the Team's Understanding of What to Develop
7.7. "It Depends": When Use Cases are a Bad Fit
7.7.1. Classic OO: Atomic Event Architectures
7.8. Usability Testing
7.9. Documentation?
7.10. History and Such
8. Coding It Up: Basic Assembly
8.1. The Big Picture: Model-View-Controller-User
8.1.1. What is a Program?
8.1.2. What is an Agile Program?
8.1.3. MVC in More Detail
8.1.4. MVC-U: Not the End of the Story
8.1.4.1. A Short History of Computer Science
8.1.4.2. Atomic Event Architectures
8.1.4.3. DCI Architectures
8.2. The Form and Architecture of Atomic Event Systems
8.2.1. Domain Objects
8.2.2. Object Roles, Interfaces, and the Model
8.2.2.1. Example
8.2.3. Reflection: Use Cases, Atomic Event Architectures, and Algorithms
8.2.4. A Special Case: One-to-Many Mapping of Object Roles to Objects
8.3. Updating the Domain Logic: Method Elaboration, Factoring, and Re-factoring
8.3.1. Creating New Classes and Filling in Existing Function Placeholders
8.3.1.1. Example
8.3.2. Back to the Future: This is Just Good Old-Fashioned OO
8.3.3. Analysis and Design Tools
8.3.4. Factoring
8.3.5. A Caution about Re-Factoring
8.4. Documentation?
8.5. Why All These Artifacts?
8.6. History and Such
9. Coding it Up: The DCI Architecture
9.1. Sometimes, Smart Objects Just Aren't Enough
9.2. DCI in a Nutshell
9.3. Overview of DCI
9.3.1. Parts of the User Mental Model We've Forgotten
9.3.2. Enter Methodful Object Roles
9.3.3. Tricks with Traits
9.3.4. Context Classes: One Per Use Case
9.4. DCI by Example
9.4.1. The Inputs to the Design
9.4.2. Use Cases to Algorithms
9.4.3. Methodless Object Roles: The Framework for Identifiers
9.4.4. Partitioning the Algorithms Across Methodful Object Roles
9.4.4.1. Traits as a Building Block
9.4.4.2. In Smalltalk
9.4.4.3. In C++
9.4.4.4. In Ruby
9.4.4.5. Coding it Up: C++
9.4.4.6. Coding Up DCI in Ruby
9.4.5. The Context Framework
9.4.5.1. The Ruby Code
9.4.5.2. The C++ Code
9.4.5.3. Making Contexts Work
9.4.5.4. Habits: Nested Contexts in Methodful Object Roles
9.4.6. Variants and Tricks in DCI
9.4.6.1. Context Layering
9.4.6.2. Information Hiding
9.4.6.3. Selective Object Role Injection
9.5. Updating the Domain Logic
9.5.1. Contrasting DCI with the Atomic Event Style
9.5.2. Special Considerations for Domain Logic in DCI
9.6. Context Objects in the User Mental Model: Solution to an Age-Old Problem
9.7. Why All These Artifacts?
9.7.1. Why not Use Classes Instead of "Methodful Object Roles"?
9.7.2. Why not Put the Entire Algorithm Inside of the Class with which it is Most Closely Coupled?
9.7.3. Then Why not Localize the Algorithm to a Class and Tie it to Domain Objects as Needed?
9.7.4. Why not Put the Algorithm into a Procedure, and Combine the Procedural Paradigm with the Object Paradigm in a Single Program?
9.7.5. If I Collect Together the Algorithm Code for a Use Case in One Class, Including the Code for All of its Deviations, Doesn't the Context Become Very Large?'
9.7.6. So, What do DCI and Lean Architecture Give Me?
9.7.7. And Remember...
9.8. Beyond C++: DCI in Other Languages
9.8.1. Scala
9.8.2. Python
9.8.3. C#
9.8.4. ...and Even Java
9.8.5. The Account Example in Smalltalk
9.9. Documentation?
9.10. History and Such
9.10.1. DCI and Aspect-Oriented Programming
9.10.2. Other Approaches
10. Epilog
A. Scala Implementation of the DCI Account Example
B. Account Example in Python
C. Account Example in C#
D. Account Example in Ruby
E. Qi4j
F. Account Example in Squeak
F.1. Testing Perspective
F.2. Data Perspective
F.2.1. BB5Bank
F.2.2. BB5SavingsAccount
F.2.3. BB5CheckingAccount
F.3. Context Perspective
F.3.1. BB5MoneyTransferContext
F.4. Interaction (RoleTrait) Perspective
F.4.1. BB5MoneyTransferContextTransferMoneySource
F.4.2. BB5MoneyTransferContextMyContext
F.4.3. BB5MoneyTransferContextTransferMoneySink
F.5. Support Perspective (Infrastructure Classes)
F.5.1. BB1Context (Common Superclass for all Contexts)
F.5.2. BB1RoleTrait (All RoleTraits are Instances of this Class)
Bibliography